home *** CD-ROM | disk | FTP | other *** search
/ Reverse Code Engineering RCE CD +sandman 2000 / ReverseCodeEngineeringRceCdsandman2000.iso / RCE / Library / Window Info / WINLOAD.TXT < prev   
Text File  |  2000-05-25  |  7KB  |  149 lines
  1.  
  2. Self-Loading Windows Applications Overview (3.1)
  3.  
  4. This topic describes the contents of a unique segment that is 
  5. found only in self-loading applications for the Windows 
  6. operating system. This segment contains six functions: three 
  7. that the application developer supplies and three that the 
  8. Windows kernel supplies. The segment also contains a table of 
  9. pointers to these functions and loader code. 
  10. This topic contains references to the Windows (new-style) 
  11. header and the data tables in a Windows executable file. 
  12.  
  13. Loader Functions
  14.  
  15. The Windows kernel provides a loader function that places 
  16. applications into memory and passes execution to a specified 
  17. entry point. Some Windows applications, however, must bypass 
  18. this kernel function and load themselves in order to be 
  19. executed correctly. For example, a compiler for Windows might 
  20. contain two floating-point modules: one requiring a math 
  21. coprocessor and one emulating the coprocessor. The standard 
  22. loader function in the Windows kernel does not provide a 
  23. method of specifying that code in one module should be loaded 
  24. in place of code in another; this means that the compiler 
  25. needs to load the appropriate code itself in order to run 
  26. efficiently and correctly. Likewise, the code for a Windows 
  27. application might be compressed with a special compression 
  28. algorithm in order to fit on a certain number of disks, but 
  29. the standard loader function does not provide a method for 
  30. dealing with a compressed file format. The application, 
  31. therefore, must load itself in order to be executed 
  32. correctly. 
  33. To indicate that a Windows application is self-loading, the 
  34. 16-bit flag value in the executable file's Windows header 
  35. must contain the value 0x0800 (that is, bit 11 must be set). 
  36. Otherwise, Windows ignores the private loader code and 
  37. installs the application by using the standard loader 
  38. functions in the Windows kernel. 
  39.  
  40. Loader Data Table
  41.  
  42. In addition to the loader functions, the first segment of a 
  43. self-loading Windows application contains a loader data table 
  44. with far pointers to each of the loader functions. The format 
  45. of this table follows: 
  46.  
  47. Location Description
  48.  
  49. 0x00     Specifies the version number (this value must be 
  50.          0xA0). 
  51. 0x02     Reserved. 
  52. 0x04     Points to a startup procedure, which the application 
  53.          developer provides. 
  54. 0x08     Points to a reloading procedure, which the 
  55.          application developer provides. 
  56. 0x0C     Reserved. 
  57. 0x10     Points to a memory-allocation procedure, which the 
  58.          kernel provides. 
  59. 0x14     Points to an entry-number procedure, which the kernel 
  60.          provides. 
  61. 0x18     Points to an exit procedure, which the application 
  62.          developer provides. 
  63. 0x1C     Reserved. 
  64. 0x1E     Reserved. 
  65. 0x20     Reserved. 
  66. 0x22     Reserved. 
  67. 0x24     Points to a set-owner procedure, which the kernel 
  68.          provides. 
  69. All of the pointers in this table must point to locations 
  70. within the first segment. There can be no fixups outside this 
  71. segment. 
  72. After the segment table for an executable file is loaded into 
  73. memory, each entry contains an additional 16-bit value. This 
  74. value is a segment selector (or handle) that the loader 
  75. created. 
  76.  
  77. Loader Code
  78.  
  79. The first segment of a self-loading Windows application 
  80. contains loader code for the six required loader functions. 
  81. The code loads and reloads segments and resets hardware. 
  82.  
  83. Loading Segments
  84.  
  85. The kernel calls the BootApp function supplied by the 
  86. application developer, instead of loading the application in 
  87. the normal manner, if the 16-bit value in the information 
  88. block for the Windows header contains the value 0x0800 (that 
  89. is, bit 11 is set). The BootApp function allocates memory for 
  90. all segments by calling the kernel-supplied MyAlloc function. 
  91. If the segment is identified as a PRELOAD or FIXED type, 
  92. BootApp also calls the LoadAppSeg function (another function 
  93. supplied by the application developer). The BootApp function 
  94. also calls SetOwner, a kernel-supplied function, to associate 
  95. the correct information block with each segment handle. 
  96. The first segment that the BootApp function should allocate 
  97. is the application's automatic data segment. This data 
  98. segment contains the application's stack. The automatic data 
  99. segment must be allocated before the BootApp function calls 
  100. the Windows PatchCodeHandle function.
  101.  
  102. Reloading Segments
  103.  
  104. In addition to loading segments, the LoadAppSeg function 
  105. reloads segments that the Windows kernel has discarded. 
  106. Because the LoadAppSeg function is responsible for reloading 
  107. segments, it must update bits 1 and 2 of the 16-bit flag 
  108. value in the segment table. (Only self-loading applications 
  109. should alter the Windows header or the data tables that 
  110. follow it.) Bit 1 specifies whether memory is allocated for 
  111. the segment, and bit 2 specifies whether the segment is 
  112. currently loaded. For a complete description of the segment 
  113. table, see Executable-File Format. 
  114. If the loader allocates memory for a segment but the segment 
  115. is not loaded (that is, bit 1 is set and bit 2 is not), the 
  116. LoadAppSeg function should call the Windows GlobalHandle 
  117. function to determine whether memory is allocated for the 
  118. segment. If memory is not allocated, the LoadAppSeg function 
  119. should call the Windows GlobalReAlloc function to reallocate 
  120. memory for the segment. 
  121. Once memory is allocated, the LoadAppSeg function should read 
  122. the segment from the executable file and call the 
  123. PatchCodeHandle function to correct each function prolog that 
  124. occurs in the segment. Once the function prologs are altered, 
  125. the LoadAppSeg function should resolve any far pointers that 
  126. occur in the segment. If the pointer is specified by an 
  127. ordinal value, the LoadAppSeg function should call the 
  128. kernel-supplied EntryAddrProc function to resolve the 
  129. address. 
  130.  
  131. Resetting Hardware
  132.  
  133. When closing a self-loading application, the kernel calls the 
  134. ExitProc function, supplied by the application developer, to 
  135. reset any hardware that a dynamic-link library may have 
  136. accessed. However, the ExitProc function does not need to 
  137. free memory or close files. 
  138.  
  139. Function Reference
  140.  
  141. This section provides information about the functions 
  142. supplied by the application developer and by the kernel for 
  143. self-loading Windows applications. 
  144.  
  145. See Also
  146.  
  147. BootApp, EntryAddrProc, ExitProc, MyAlloc, PatchCodeHandle, 
  148. LoadAppSeg, SetOwner 
  149.